home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group92c.txt / 000013_icon-group-sender _Sun Oct 4 20:38:26 1992.msg < prev    next >
Internet Message Format  |  1993-01-04  |  1KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 7 Oct 1992 05:56:27 MST
  2. Date: 4 Oct 92 20:38:26 GMT
  3. From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!uwm.edu!ux1.cso.uiuc.edu!uchinews!quads!goer@ucbvax.Berkeley.EDU  (Richard L. Goerwitz)
  4. Organization: University of Chicago Computing Organizations
  5. Subject: Re:  storing objects
  6. Message-Id: <1992Oct4.203826.22606@midway.uchicago.edu>
  7. References: <9210040357.AA05603@gremlin>
  8. Sender: icon-group-request@cs.arizona.edu
  9. To: icon-group@cs.arizona.edu
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13. wgg@CS.UCSD.EDU (William Griswold) writes:
  14. >
  15. >Well, you might be able to exploit the properties of your specific tables.
  16. >For example, if your keys and elements are all ``printable'', then...
  17.  
  18. What they are are LR(1)-generated action and goto tables.  If I don't opti-
  19. mize (or do so at run-time), then I can do what you suggest.  The trouble
  20. is that one of the big optimizations that takes some time to sort out is
  21. based on the property that rows in the action table are often the same, so
  22. that one can store pointers to one single structure, instead of repeating
  23. identical rows.
  24.  
  25. -- 
  26.  
  27.    -Richard L. Goerwitz              goer%midway@uchicago.bitnet
  28.    goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
  29.